System Life Cycle Reliability Engineering.
현대 사회는 제품이 지속적으로 향상되고 어떤 경우에는 컴퓨터가 실제로 가격이 하락한다.
1959년 자동차의 표준 보증 기간은 3개월 이었고,
1960 년에 생산된 TV 세트의 평균 수명은 2년 미만이었다.
진공관을 고체(Solid state )전자 장지로 교제하는 것과 같은 기술적인 혁신은 신뢰성을 높이고 비용을 절감하는데 도움이 되었습니다.
그러나 신뢰성과 비용의 향상은 일반적으로 장기간에 걸진 작은 개선의 결과이다.
"지속적인 개선 속적인 개선 프로그램의 핵심 요소는
(1)고장의 우선 순위 결정,
(2)고장의 근본 원인 결정,
(3)시정 조치의 결정과 통합,"
(4)프로세스가 원하는 조건하에서 제어되는지 확인하는 것이다.
근본 원인 분석 (RCA)은 원래의 문제를 일으킨 고장 메커니즘이나 원인을 확인하는 정도까지 문제를
평가하는 프로세스이다.
근본 원인 프로세스는 문제 진술을 결정하고, 잠재적인 원인을 전개하고 원인을 평가하고, 주요 원인을 격리하고,
주요 원인을 검증하는 논리적 순서를 포함한다.
프로세스는 원인이 어떻게 발생했는지를 설명하기 위해 무엇을, 왜, 언제, 어디서, 누가를 처리 할 수 있는
논리적 순서로 생각할 수 있다.
이 도구는 적절한 예방 조치를 결정하기 위해 경험한 문제점의 세부 사항을 이하하는 데 도움을 주기 위해 적용된다.
근본 원인 분석은 대개 제품 개발 프로세스(PDP)의 생산 단계에서 적용되지만
제품 설계/프로세스 개발 및 PDP 검증 단계에서 적용할 경우 더 효과적 일 수 있다.
생산 단계에서 근본 원인 분석은 생산에서 나타난 고장에 대한 시정 조치가 즉각적인 주의를 요구하기 때문에 자연스러운 것이다.
그러나 회사가 잘못된 시정 조치를 취할 가능성을 방지하기 위해 개발 단계에서 RCA를 통합하는 것이 좋다.
고장 메커니즘을 설계에서 제거하기 위해 정확한 시간을 정의하는 것은
엔지니어링 개발 비용이 생산 단계에서 발생하는 비용보다 적기 때문에
설계 개발 단계에서 엔지니어링 팀에게 이점이 된다.
근본 원인 분석은 설계 또는 프로세스 복잡성 수준 (구성 요소, 하위 시스템 또는 시스템 수준)및
부품 상태 (신규, 수정 또는 이월)에 적용 할 수 있다.
근본 원인 분석의 참가자는 엔지니이링 커뮤니티 (설계, 프로세스, 서비스 등)의 많은 대표자를 포함하며
품질, 신뢰성 또는 제품 보중 담당자를 포함한다.
문제의 가능한 원인에 대해 결론을 내리기 위해 그룹에 지시하는 지식과 경험을 가진 것은 제품 엔지니어이다.
신뢰성 엔지니어는 그룹이 실험 및 분석에 대한 배경 자료 및 협의에 기여하고 논리적인
근본 원인 분석 순서를 지시 할 수 있다.
근본 원인 분석의 실행은 주로 가능한 원인에 대한 문제의 단계별 검토와 평가를 포함한다.
프로세스의 각 단계를 구현하는 데는 원인을 유도 할 수 있는 데이터, 분석 및 해석을 지원하여
각 목표를 처리하는 그룹의 집단적 노력이 필요한다.
이 과정에 대한 간단한 검토가 이어지고 그림 2.6에서 더 자세히 설명된다
1. 문제점 진술을 정의하고 문제와 관련된 조건을 처리하십시오.
특정 문제 진술과 관련이 있거나 다를 수 있는 요소를 기술하십시오
2. 지정된 문제에 대한 가능한 원인을 설명하고 정의하십시오.
문제와의 관계를 지지하거나 반증 할 수 있는 배경 자료를 가지고 가능한 원인을 제시하십시오.
FMEA, FTA, 엔지니어링 고장 분석, 실험적 시험 결과, 시뮬레이션 연구, 이전의 시험 결과 등으로 부터
이러한 정보를 얻으십시오.
정량적으로 또는 질적으로 시험 할 수 있는 가설의 개발은 원인과 결과를 탐구하기 위해 필요한다.
3. 통계 도구 또는 엔지니어링 평가를 사용하여 가능한 원인 목록을 평가하고 문제의 진정한 원인에 대해
가장 가능성 있는 후보를 격리한다.
사용 된 평가 접근법은 가설 검정 및 시험 분식 기법과 같은 정량적 통계 접근법을 포함 할 수 있다.
데이터가 본질적으로 질적이라면, 의사 결정 기술 (확률론적 데이터의 유무에 관계없이)의 사용이
진정한 원인을 확인하기 위해 통합 될 수 있다.
두 경우 모두 정식 (의사 결정 트리 또는 페이 오프 테이블)또는 비공식(비교 등)의사 결정 기술을 사용하여
가능한 원인을 진정한 원인으로 한정 할 수 있다.
4. 문제를 재현하는 데 도움이 되는 테스트, 실험, 프로세스 데도 등을 수행하여 진정한 원인의 선택을 확인하십시오.
환경 조건의 변화에 따라 신뢰를 구축하기 위해 여러번 반복하십시오.
Figure 2.6 근본원인 분석 프로세스
근본 원인 분석은 문제를 평가하고, 올바른 종류의 질문을 제기하며, 문제의 가능한 원인을 찾아 내고
파악할 수 있는 생각을 전달하는 상식적인 접근 방식을 제공한다.
제품 설계 및 프로세스의 고장 메커니즘 결정을 지원하는 데 사용되는 도구이다.
근본 원인 분석의 장점 중 주요 내용은 다음과 같다 .
• 특정 문제에 대한 원인의 확인 및 확인을 지시하는 논리적 사고 프로세스를 제공한다
• 고장 메커니즘 식별 및 구성 방법을 공식화 한다.
제품 설계 및 프로세스의 위험 평가를 위한 중앙 문서인 FMEA에 대한 이러한 메커니즘을 정당화 한다
• 가능한 원인을 판별하고 그 원인을 평가하기 위한 단순하지만 적응 가능한 방법을 제시한다.
• 제품 개발 프로세스의 모든 단계에서 적응 가능한다.
테스트 또는 예비 생산 프로세스가 실패한 후에 고장 분석과 결합될 때 가장 유익한다.
• 근본 원인을 결정할 때 많은 다른 공학 분야를 포함 할 수 있다.
문제 해결의 공통 목표를 위해 그룹을 모으는 데 도움을 줍니다.
문제 정의 (Problem Definition) 소리가 나는 음악 장치가 식별 가능한 소리를 내지 못한다.
문제 사양 (Problem Specificatiqn)
What : 사운드를 생성하지 않는 '모델 X 사운드 생성 장지'
Where.: 마케팅 환경에서 5개 지역 중 4개 지역
When: 2주 전에 시작되었습니다
Extent: 100개 생산 당 3개 부품
모든 고장 난 장치에는 소리가 나지 않는다,
장치가 작동하지 않는 비율이 증가한다
가능한 문제점 제공자 (원인)
1. 장치 내부의 단락(Short)된 양극 단자
2. 전기 접점에 과도한 산화물 축적
3. 독립형 컨트롤러 전기 접지의 손실
4. 음향 발생 장치 시스템의 개방 회로
5. 극한의 온도 또는 습도로 사운드를 생성하는 구성품에 대한 반응
6. 선적 또는 조립시점 기기의 잘못된 취급
7. 전환 버튼 고정
원인 평가
통계 도구 # 1 :
원인 및 결과 다이어그램은 현장 및 현재 FMEA에서의 이전 고장 모드 경험으로 구성되었습니다.
통계 도구 # 2
파레토 차트는 최근 경험한 고장 모드 분포에 따라 작성되었습니다.
이 파레토 자트는 이전 디자인의 이전 차트와 비교된다.
과거에는 산화된 접촉을 기반으로한 작동 불능 사운드 생성 장치의 잠재력이 있었지만
중요하지는 않았습니다.
3개월 동안 생산 된 부품을 기준으로 현재 파레토 차트를 검사한 것은 산화 접촉 조건과
분명히 관련이 있었다.
통계적 도구 # 3
산화된 접속에 기여할 수 있는 요인을 조사하기 위해 설계된 실험이 수행되있다.
결과는 특정 로트 접점 재료의 재료 구성과 결합 된 핸들링 기술이 부식 된 접점 생성에
중요한 영향이 있습니다는 것을 나타냅니다.
추가 조사는 합금 제조 공정에 존재하는 모든 산화제를 제거하기 위해 적절히 열처리되지 않은
접촉 재료와 반응기 핸드로부터의 수분으로 인한 접속의 오 취급이 반응했다는 것을 밝혀냈다
확인 된 원인 확인
확인 작업은 원래 설계된 실험에서 정의된 것과 동일한 조건을 사용하여 수행되었습니다.
두 번째 테스트의 결과는 첫 번째 실험에서 도달 된 결론을 확인했다.
시정 조치
시정 조치는 조립 도중 재료 취급자의 공정 제어를 향상시키기 위해 수행되었습니다.
이 특별한 작업에는 장갑이 필요했다. 또한, 합금의 열처리 공정을 면밀히 검토하여
가열 냉각(Anneling)단계에 진입하는 불순물을 확인하여 산소에 대한 반응성 합금을 생성시켰다
문제의 근본 원인과 경우에 따라서는 해결책을 찾기 위해 '5Why' 기술을 활용할 수 있다.
“5 Why 는 실제로 4,5,5 또는 7 Why 가 있다.
워싱턴 기념비 방문객은 기념비가 닫히는 것을 보고 실망했다.
그러므로 다음과 같은 5 Why 를 적용했다
1. 기념비가 왜 닫혀 있습니까?
답변 : 대리석 표면을 청소하기 때문에.
2. 기념비에서 왜 청소가 필요한가요?
답변 : 기념비에 독특한 작은 거미줄 산하를 제거하기 위해.
3. 왜 기념비에 거미가 있습니까?
답변 : 거미들이 첨탑의 꼭대기 근저에 있는 모기를 먹기 위해 오기 때문에
4. 그렇다면 기념비에 왜 작은 곤충들이 있습니까?
답변 : 밤에는 조명에 끄기 때문에.
5. 밤 전체 또는 대부분의 시간 동안 조명을 끄지 않는 것이 어떻습니까? (잠재적 해답)
때로는 해결책이 없지만 다음의 신화적 이야기는 어쨌든 계몽적인 이야기 이다.
워싱턴 주에서 휴스턴까지의 우주 로켓 선적은 값 비싸고 시간이 많이 걸렸다.
트럭으로 운송 할 때 전화선과 전력선을 줄여야 한다.
특대 트레일러가 필요했다.
전면 및 후면 신호 차량이 필요했다.
평균 이동 거리는 '100 마일/일” 이었다.
따라서 제조 시설의 임원은 다음과 같은 질문을 던졌습니다.
1.왜 유닛을 레일로 운송하지 않습니까?
답변 철도 터널이 너무 좁다.
2.터널이 너무 좁은 이유는 무엇입니까?
답변 : 레일 너비와 관련이 있다.
3. 왜 미국의 레일은 4ft 8 ½ in 폭입니까?
답변 . 영국 레일 폭을 기준으로 한다.
4. 영국의 폭이 왜 그렇게 좁습니까?
답변 . 그것은 로마 전자 또는 광산 카트 폭과 관련이 있을 수 있다.
5 그럼에도 불구하고 영국이나 로마 출신에 관계없이 왜 이 너비입니까?
답 : 부작된 하네스가 있는 말 (또는 노새)의 후면보다 약간 넓습니다.
이 경우 로켓 동체는 여전히 철도로 운송 될 수 없다.
| System Definition | Subsystem Defini60n | ||
|---|---|---|---|
| Conceptual Design | Preiminary Design |
Detailed Design |
Fabrication Assembly, Intergration & Test |
| Needs analysis & reliability requirements. Prediction: part count and stress. Critical items control. Life cycle cost analysis. | FTA. FMEA. Robust design & DOE. Sneak circuit analysis. Thermal analysis. Worst case analysis | Accelerated life testing. RGT & TAAF. FRACAS. ESS & vendor control. PRAT. Design review. | |
Project Scheduling.
Gantt chart.
Network technique.
Critical path method (CPM).
Program evaluation & review technique (PERT).
제품 수명주기에 대한 한 가지 설명은 제품 신뢰성 - 신뢰도 프로그램 정의를 위한
RAC 청사진에서 제공된다. RBPR-I (RAC 1996)
| 제품 사이클 Product Cycle |
신뢰성 포커스 (Reliability Focus) |
|---|---|
| 개념/기획 Concept/Planning | • 아이디어 공식화 및 자원 추정 • 리스크 요구 사항 파악 • 프로그램 목표 수립 |
| 설계/개발 Design/Development | • 니즈 (필요사항)및 요구 사항 파악과 할당 • 대안 대체안의 제시 • 제품 설계 및 테스트 • 제조, 운영 및 유지 보수 작업 전개 |
| 생산/제조 Production/Manufacturing | • 제조 절차 정제 및 구현 • 생산 설비 완결 • 품질 프로세스 확립 • 제품 구축 및 분배 |
| 운영/수리 Operation/Repair | • 운영, 설치 및 교육 절차 구현 • 수리 및 유지 보수 서비스 제공 • 보증 품목 수리 • 성과 피드백 제공 |
| 마모/폐기 Wear out/Disposal | • 재생 빛 폐기 작업 수행 • 잠재적인 마모 문제 해결 : |
Table 28 제품 수명주기와 신뢰성 포커스와 관계
제품 수명주기와 신뢰성의 관계는 교차 기능 개발 팀에 의해 가상의 신뢰성 프로그램을 적용 할 때
직면하게 되는 활동과 과제를 논의함으로써 서술할 수 있습니다
제품 수명주기의 '개념/계획 단계”에서 핵심 신뢰성 업무가 정의된다.
이러한 목표는 보증성과 및 마케팅 계획을 포함하여 조직의 전략적 목표에 근거해야 한다.
수락할 수 있는 수준에서 신뢰성 목표를 달성 할 수 있는 제품 설계의 능력을 입증하는
신뢰성 프로그램 계획을 확정해야 한다.
신뢰성 프로그램 계획에는 중요한 일정이 명시된 예비 일정이 포함되어야 한다.
환경 특성 분석 및 응용 분석도 이 단계에서 완료되어야 한다.
임무 프로파일(특정 임무의 시작에서 완료까지의 사건과 환경에 대한 시차적인 설명)이 포함되어야 한다.
이전의 유사하거나 경쟁적인 제품의 과거 데이터를 기반으로 한 제품 개념에 대해
초기에 신뢰성 예측을 획득해야 한다.
핵심 하위 시스템에 대한 시스템 신뢰성 할당을 위한 초기 모델은 주어진 경제 제약 조건 내에서
신뢰성 목표를 달성할 타당성을 검증하기 위해 정의되야 한다.
시스템 신뢰성이 '예산 책정'되거나 하위 시스템에 할당되고 차례로 구성품 수준으로 할당되면
신뢰성 성능의 정량화가 계속된다.
설계 양식을 취함에 따라 더 정확한 예측이 완료 될수 있다.
이 예측은 유사한 방식으로 적용될 때 제품에 대해 선택된 구성품의 이력 데이터를 기반으로 한다.
구성품 조달 또는 설계 활동을 위한 대안의 분석 및 비교가 설계 목표 및 신뢰성 목표를 충족시키는
가장 비용 효율적인 접근 방법을 식별하기 위해 수행된다.
제품의 특성에 따라 여러 가지 신뢰성 도구를 적용 할 수 있다.
시험 활동은 설계의 유효성을 검사하기 시작할 수 있다.
시스템은 이러한 시험과 후속 시험동안 발생하는 고장의 근본 원인을 추적 할수 있어야 한다.
시험을 진행중인 모든 장치에 대해 작동 시간 또는 작동주기가 추적된다.
종종 시험은 고장을 신속하게 유도하기 위해 '가속' 한다.
설계 취약점을 해결하기 위한 시정 조치 시스템을 설계 개정 문서 시스템에 통합해야 한다.
생산 공정의 시작 단계에서 제조 공정이 제품 설계의 신뢰성에 악영향을 미치지 않는지를 확인하는
추가 시험을 위해 주가 유닛(UNIT)을 제출하기도 한다.
초기 생산 유닛의 시험은 현재까지 제품의 신뢰성에 대한 가장 정확한 통찰력을 제공하야 한다.
허용할 수 없는 고장 모드 또는 고장률을 저리하기 위해 공정 중 고장, 고객 수락 고장 및 보증 고장을
모니터링해야 한다.
제품의 수명주기 초기에 사용된 많은 신뢰성 도구 및 예측 기술은 생산 단계에서 다시 적용될 수 있다.
분석에 사용할 수 있는 추가 데이터가 주어지면 제품의 신뢰성을 보다 정확하게 결정할수 있다.
제품이 마모 단계로 접어들 때 진행중인 생산을 향상 시키거나 필드 유닛의 유효 수명을 연장하거나
시정 될 수 있는 새로운 고장 메카니즘이 관측될 수 있다.
폐기 문제는 제품 수명주기의 설계 단계에서 다루어저야 한다.
그러나 때로는 입법 조치 또는 대중 여론 변화와 같은 추가적인 노력이 필요할 수 있는 문제가 발생한다.
신뢰성 성장올 위한 MIL-STD-721C (1981)의 정의는 다음과 같다 :
아이템 설계 또는 제조상의 결함을 성공적으로 시정함으로써 야기된 신뢰성 파라미터의 향상
많은 신뢰성 도구의 적용은 측정된 신뢰성의 증가로 최고조에 달할 수 있다.
신뢰성의 성장을 평가할 수 있는 다양한 기법이 있다.
MIL-HD3K-189(1981)은 시간 경과에 따른 계획된 신뢰성 향상과 비교하여 입증된 신뢰성을
평가하기 위해 적용될 수 있는 상세한 프로그램 관리 및 수학적 모델을 식별한다.
본질적으로, 학습 곡선 모델에 기초한 이상적인 신뢰도 성장 곡선은 제품의 계획 단계에서 개발된다.
Test Analyze and Fix 프로그램의 적용을 통해 입증된 신뢰성 곡선이 구축된다.
이 두 곡선 사이의 차이는 프로그램의 신뢰성 목표 달성에 대한 통찰력을 제공 할 수 있다.
신뢰성 전문가가 적용하는 두 가지 주요 모텔은
Duane (James T. Duane)모델과 AMSAA 모델(Dr. Larrycrow가 개발)이다.
이 모텔은 이 입문서의 뒷부분에서 자세히 설명한다.
MIL-HDBK-781A (1996)는 일반적인 신뢰성 요구 사항으로서 통합 신뢰성 시험 계획을 정의한다.
시험 노력의 중복을 피하고 결함이 간과되지 않도록 보장하기 위한 통합된 신뢰성 시험 계획은
신뢰성 데이터가 다른 모든 테스트에서 파생된다는 것을 보장하는 절차를 정의해야 한다.
통합된 시험 계획은 사용을 위해 선택된 시험계획, 리스크 결정 및 환경 시험 조건에 대한
설명을 고려해야 하며 프로그램 수명주기 단계에 따라야 한다
개발 프로그램에서 수행되는 모든 활동에서 얻을 수 있는 정보의 적용 가능성을 평가함으로써
신뢰성 측정의 신뢰도를 높일 수 있다.
통합 일정은 제품 신뢰성을 입증하기 위해 '결합 된'많은 데이터 소스를 반영해야 한다
이 입문서의 뒷부분에서 설명하는 순자적 시험 계획 (Sequential test plan)기법은 통합된 접근 방식을
설계 할 때 고려해야 한다.
이러한 계획은 종종 수용 가능한 위험 수준에서 제품 신뢰성을 가장 신속하게 결정하게 된다.
제품 개발 또는 프로그램 일정 또한 신뢰성 계획 및 활동 일정과 통합되어야 한다.
제품 개발/프로그램 계획의 주요 일정은 신뢰성 프로그램의 핵심 요소 또는 작업 완료와 일치해야 한다.
수명주기 비용은 장비 또는 프로젝트의 수명기간 동안 사용한 총 비용에 대한 조사 및 추정치에 의해
결정된 장비 및 프로젝트의 개시부터 폐기까지의 예상 비용의 합계이다.
수명주기 비용 분석의 목적은 설계, 개발, 생산, 운영, 유지 보수, 지원 및 비용을 포함하는
비용 요소를 고려하면서 가장 장기간의 소유 비용이 달성되도록 일련의 대안 중에서 가장 비용 효과적인 접근 방식을 선택하는 것이다.
예상 수명 수명 동안 주요 시스템의 일반적인 수명주기 비용 단계는 다음과 같습니다.
• 취득 비용 : 구매, 엔지니어링, 설치, 교육 및 운송 비용
• 운영비 : 인건비, 유틸리티, 소모품, 지속적인 교육, 법률, 감가상각비, 낭비
• 계획 보전 비용 : 노동, 자재, 예비 부품, 수리
• 비(非)계획 보전 비용 : 노동, 자재, 예비 부품, 생산성 손실
• 전환, 해체 및 처분 비용 : 처분, 제거, 청소, 부지 복원(Restoration of site), 교정, 자산 처분
수명주기 비용 분석은 각 단계의 비용 견적을 사용하여 순수 현재 가치(NPV : net present value)
방법을 사용하여 현재 기간으로 변환한다
불확실성과 발생 요인의 확률은 각 기여 비용에 배분 될 수 있다.
몬테 카를로 시뮬레이션 모델은 또한 수명주기 비용을 산정하는데 사용될 수 있다.
가능한 경우 비용 산정을 결정할 때 유사 제품 또는 프로젝트의 과거 데이터를 고려해야 한다.
수명주기 비용 모델이 개발되면 다양한 구성 요소의 신뢰성을 변경하는 효과가
최적 또는 최저 수명주기 비용을 결정하는 데 사용된다. (Barringer, 1997)
효율적인 품질 계획을 위해서는 소프트웨어 결함 탐지 및 제거의 비용 효과도 고려해야 한다.
초기 개발 단계에서의 결함 제거는 일반적으로 비용이 적게 든다.
결함이 주입되는 위치와 시간에 상대적으로 더 가까울수록 제거 및 재 작업 노력이 줄어 든다.
Fagan (1976)은 상위 수준의 설계, 하위 수준의 설계 및 코드 검사 수준에서 수행된 재 작업은
프로세스의 마지막 절반에서 수행되는 것보다 “10에서 100 배'로 저렴한다.고 주장했다
(코드 통합 후의 공식 테스트 단계)
수명주기 비용을 최소화하기 위해 신뢰성 생산 모듈을 생성하는데
신뢰성 엔지니어는 "관측된 데이터 및 경험"을 사용한다.
결함 제거는 소프트웨어 프로젝트의 가장 큰 비용 중 하나이며,
프로젝트 일정에 결정적으로 영향이 있다.
따라서 검사 및 테스트와 같은 결함 제거 프로세스의 효율성을 측정하는 것이 중요한다. (Kan, 1995)
Fagan (1976)은 결함 제거 효과의 개념에 대해 다루었다.
그는 에러 검출의 효율성을 다음과 같이 정의했다
$$$ \frac{검사에 의한 에러 검출} {검사 이전에 생성된 전제 에러}\times 100 \% $$$
1980 년대 중반에 Jones (1991)는 결함 제거 효과에 대한 이러한 측정을 확대했다.
그의 정의에서 제거 효율 공식의 분모에는 필드에서 발견된 결함이 포함되었습니다.
$$$ \frac{제거 활동에 의한 결함 파악} {제거 활동 시점에서의 결함 존재}\times 100 \% $$$
혹은
$$$ \frac{결함 파악} {결함 파악 + 미지의 결함(파악 지연)}\times 100 \% $$$
결함 제거 효과를 정의하기 위해 결함 주입 및 결함 제거와 관련된 개발 프로세스의 활동을 이해해야 한다.
결함은 제품 또는 중간 소프트웨어 실체(즉 설계 문서)의 수명주기 동안 다양한 단계로 주입된다.
| 개발 단계 | 결함 주입 Defect Injection | 소프트웨어 결함 제거 |
|---|---|---|
| 요구분석 (Requirements) | 요구 수집 프로세스 및 요구 사양의 개발 | 요구 사항 분석 및 검토 |
| 상위 수순 설계 (High Level Design) | 설계 작업 Design work | 상위 수준의 설계 검사 |
| 하위 수준 설계 (LOW Level Design) | 설계 작업 Design work | 하위 수순의 설계 검사 |
| 코드 실행 (Code Implementation) | 코딩 Coding | 코드 검사 |
| 유닛 시험 (Unit Test) | 나쁜 버그 수정, 시정 Bad bug fixes | Unit testing |
| 통합 (Integration) | 나쁜 버그 수정, 시정 Bad bug fixes | Integration testing |
| 시스템 시험 (System Test) | 나쁜 버그 수정, 시정 Bad bug fixes | System Testing |